Hi SJH,

Can you isolate a simple case that fails?

Also how are your A B C axes defined?  Are they pure angles or angles with a non zero radius?

The A B C axes can operate in different modes. 

#1 They can be "Linear" axis.  For example the A axis might be parallel with the Z axis.  In this case I think a move in XYA should be handled like XYZ.  In these linear cases the Trajectory planner assumes all the axes that move are orthogonal.

#2 They can have a angle and radius.  This might be like engraving on a cylinder pointed in the X direction.   In this case a move in the A Axis results in motion perpendicular to the X Axis.

#3 Or they can be pure angular Axes (Radius=0).  And further a particular move can involve XYZ or only angles

 

Hi Tom,

We are in the process of debugging our 5-axis changes.  Occasionally, we are getting floating point errors in void RoundCorner(int is) in TrajectoryPlanner.cpp.  We haven't touched that code, but nevertheless we're probably torturing it.  Just wondering if you can provide some insight.

It fails at the line
double l=sqrt(R*R-Z*Z);

in the loop where it is generating the facet segments.  R is less than Z.  It seems to be something to do with our segments having relatively large changes in the A,B axes and small changes in XYZ.  So (local var) 'Z' is computed from the 5-D "chord length" of the segment, however the corner radius R is calculated in 3-D since a 5-D radius is probably difficult to define.

Perhaps the calculation of Z should ignore the rotary axes?

I must admit to not understanding the implications of continuous 5-axis on this algorithm.  After all, what is a corner arc in 5-D?  I can understand the concept of a 5-D quadratic Bezier curve, which basically amounts to accelerating each axis independently to achieve the required velocity change.  But an arc doesn't seem to have the required degrees of freedom.

Regards,

SJH

Hi SJH,

It isn't clear to me why TCPC would change things.  I would think you would want to smooth/round the xyz path regardless.

Regarding quadratic or cubic beziers: Sounds interesting I suppose that would be reasonable.  But the problem I have with those is that I don't know how to determine them in a way with a known path tolerance.  

Also I wonder if keeping the Time the same would work where the original uses constant velocity and the other accelerates/decelerates.  I've seen weird results (ie curly queues or huge Jerks) if the time span is improper.

Another issue is that using a single formula for a curve (rather than small line segments) means that each portion of the curve can't be optimized the way it currently is.  For example consider a quarter circle curve.  The velocity/acceleration limits might be different for x and y.  Or even if they are the same when moving both the capability may be higher than either individually.   Also for non-linear systems it is difficult to determine if any of the actuator constraints are violated at any portion of the curve.

If you are able to determine the angle changes are minor, then these issues may not be significant.

HTH

Regards

TK

 

Hi Tom,

As I mentioned, although in passing only, we have made extensive changes to CoordMotion.cpp and Kinematics.cpp to support g43.5 (TCPC) modes, so in this case there is no concept of rotary axis "radius" since the g-code IJK coordinates transform to a tool orientation and XYZ are relative to the (rotating) workpiece.  I think our problem arises when XYZ are not moving much, but the orientation vector is.  There are several unsatisfactory hacks I put in just to get it working.  Basically, a "pure angular" move should always execute at a rate limited by axis motor constraint, since the tool tip is not moving w.r.t. the workpiece.

So I can't really give a test case that will work for you.  No problem, we knew that we were on our own for this stuff.

We have turned off the "corner rounding" for now.  I guess that's like specifying a corner tolerance of 0.

Down the track, when we start optimizing for surface quality, I am thinking along the following lines.  (Please tell me now if you think it would be a bad idea):

Once the segments are "done" and ready for download to the kflop, we do a final scan through them and add some trip states to try to match up velocity vectors at the segment junctions.  Since feed motion is only 2nd order (3 trip states) we can potentially rewrite segments to insert some higher order velocity matching.  Probably using quadratic or cubic beziers to work out the polynomials.  We should be able to do this while keeping total move time invariant.

I think we can also automatically recognize when the post processor has discretized a curved tool path, by looking for relatively short segments with small velocity deltas.  So segments can be flagged as belonging to a "smooth path".

Regards,

SJH

On Tue, Oct 18, 2016 at 4:50 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

Can you isolate a simple case that fails?

Also how are your A B C axes defined?  Are they pure angles or angles with a non zero radius?

The A B C axes can operate in different modes. 

#1 They can be "Linear" axis.  For example the A axis might be parallel with the Z axis.  In this case I think a move in XYA should be handled like XYZ.  In these linear cases the Trajectory planner assumes all the axes that move are orthogonal.

#2 They can have a angle and radius.  This might be like engraving on a cylinder pointed in the X direction.   In this case a move in the A Axis results in motion perpendicular to the X Axis.

#3 Or they can be pure angular Axes (Radius=0).  And further a particular move can involve XYZ or only angles

These higher dimensions makes my head spin.

Regards
TK

On 10/18/2016 12:03 AM, Hardy Family hardy.woodland.cypress@gmail. com [DynoMotion] wrote:

 

Hi Tom,

We are in the process of debugging our 5-axis changes.  Occasionally, we are getting floating point errors in void RoundCorner(int is) in TrajectoryPlanner.cpp.  We haven't touched that code, but nevertheless we're probably torturing it.  Just wondering if you can provide some insight.

It fails at the line
double l=sqrt(R*R-Z*Z);

in the loop where it is generating the facet segments.  R is less than Z.  It seems to be something to do with our segments having relatively large changes in the A,B axes and small changes in XYZ.  So (local var) 'Z' is computed from the 5-D "chord length" of the segment, however the corner radius R is calculated in 3-D since a 5-D radius is probably difficult to define.

Perhaps the calculation of Z should ignore the rotary axes?

I must admit to not understanding the implications of continuous 5-axis on this algorithm.  After all, what is a corner arc in 5-D?  I can understand the concept of a 5-D quadratic Bezier curve, which basically amounts to accelerating each axis independently to achieve the required velocity change.  But an arc doesn't seem to have the required degrees of freedom.

Regards,

SJH

Hi SJH,

This is very interesting.  I can't say I fully understand it.  Here are some questions:

#1 it isn't clear if you are intending to only use the Bezier to define the path, or also using it to define the motion vs time.

#2 can you elaborate more on how the path error is controlled?

 

We have made some progress.  The corner rounding now uses a cubic Bezier instead of a circular arc, so it is more robust for 5 axis.  Even a break angle of 90deg gives close enough to an arc.

It's actually not difficult to compute corner tolerances for the Bezier.  There's a simple formula for making a close approximation to a circular arc, and if an initial guess it taken, then because everything is linear at this scale, it is simple to scale it so that it passes a known tolerance from the specified point (segment intersection in this case).  The math is fairly trivial compared to the tangent arc case.  (Ok, maybe it's just me but I prefer vector math to trig!)

I also worked out a way of manipulating it so that it can match different tangential speeds at either end, while still being within the specified tolerance.

In RoundCorner(), it subdivides the Bezier into linear segments at variable parameter (t) intervals so as to maintain a specified target "velocity impulse" i.e. radial velocity increments at the segment junctions.  If the segments become too short (about 360us) then we reduce the MaxVel to force it to slow down enough that the impulses are not exceeded.  If there is different feed rate for entry and exit segments, then the change in feed rate is distributed along the curve linearly by t.  (Our post processor generates lower F numbers when it thinks there is fine detail, then speeds up on the "straights", so this smooths things out a bit, although it's probably redundant since the motion planner does this automatically.  But maybe it allows the segments to be "done" with less work.)

Since this is all done in actuator space, and each axis component is separable, the adaptive step size allows handling different actuator capability etc.

So now we are generating maybe 1-2000 LHex1 commands per second, or about 1Mbit/sec on the USB.  I think we would sustain this on a complex mold pattern.

I haven't tested this yet on a real machine, only a bare kflop, but analysis of the dumped segment output looks good so far.

Hopefully this will be satisfactory, but since our machine is intended for very fine mold work we wish to have the best finish possible.  We'll see how it goes, but what do you think of the prospect of adding native Bezier support to the kflop firmware?  This would be a command which allows two control points in addition to the start+end points, then the kflop would use Bezier interpolation instead of the current linear.  This would allow us to basically do away with the complex curve subdivision in RoundCorner(), and would reduce the bandwidth requirement, and of course it would give the ultimate smoothness.

Your point about losing some level of control as the curve progresses is valid, but I think if the use of this is for replacing multiple curve-approximating segments (at roughly constant speed), then the PC library can optimize its use fairly well.  Indeed, my happiness would be complete with kflop Beziers.  Such power! :-)

Regards,

SJH

On Thu, Oct 20, 2016 at 9:05 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

It isn't clear to me why TCPC would change things.  I would think you would want to smooth/round the xyz path regardless.

Regarding quadratic or cubic beziers: Sounds interesting I suppose that would be reasonable.  But the problem I have with those is that I don't know how to determine them in a way with a known path tolerance.  

Also I wonder if keeping the Time the same would work where the original uses constant velocity and the other accelerates/decelerates.  I've seen weird results (ie curly queues or huge Jerks) if the time span is improper.

Another issue is that using a single formula for a curve (rather than small line segments) means that each portion of the curve can't be optimized the way it currently is.  For example consider a quarter circle curve.  The velocity/acceleration limits might be different for x and y.  Or even if they are the same when moving both the capability may be higher than either individually.   Also for non-linear systems it is difficult to determine if any of the actuator constraints are violated at any portion of the curve.

If you are able to determine the angle changes are minor, then these issues may not be significant.

HTH

Regards

TK

On 10/18/2016 5:36 PM, Hardy Family hardy.woodland.cypress@gmail. com [DynoMotion] wrote:

 

Hi Tom,

As I mentioned, although in passing only, we have made extensive changes to CoordMotion.cpp and Kinematics.cpp to support g43.5 (TCPC) modes, so in this case there is no concept of rotary axis "radius" since the g-code IJK coordinates transform to a tool orientation and XYZ are relative to the (rotating) workpiece.  I think our problem arises when XYZ are not moving much, but the orientation vector is.  There are several unsatisfactory hacks I put in just to get it working.  Basically, a "pure angular" move should always execute at a rate limited by axis motor constraint, since the tool tip is not moving w.r.t. the workpiece.

So I can't really give a test case that will work for you.  No problem, we knew that we were on our own for this stuff.

We have turned off the "corner rounding" for now.  I guess that's like specifying a corner tolerance of 0.

Down the track, when we start optimizing for surface quality, I am thinking along the following lines.  (Please tell me now if you think it would be a bad idea):

Once the segments are "done" and ready for download to the kflop, we do a final scan through them and add some trip states to try to match up velocity vectors at the segment junctions.  Since feed motion is only 2nd order (3 trip states) we can potentially rewrite segments to insert some higher order velocity matching.  Probably using quadratic or cubic beziers to work out the polynomials.  We should be able to do this while keeping total move time invariant.

I think we can also automatically recognize when the post processor has discretized a curved tool path, by looking for relatively short segments with small velocity deltas.  So segments can be flagged as belonging to a "smooth path".

Regards,

SJH

On Tue, Oct 18, 2016 at 4:50 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

Can you isolate a simple case that fails?

Also how are your A B C axes defined?  Are they pure angles or angles with a non zero radius?

The A B C axes can operate in different modes. 

#1 They can be "Linear" axis.  For example the A axis might be parallel with the Z axis.  In this case I think a move in XYA should be handled like XYZ.  In these linear cases the Trajectory planner assumes all the axes that move are orthogonal.

#2 They can have a angle and radius.  This might be like engraving on a cylinder pointed in the X direction.   In this case a move in the A Axis results in motion perpendicular to the X Axis.

#3 Or they can be pure angular Axes (Radius=0).  And further a particular move can involve XYZ or only angles

These higher dimensions makes my head spin.

Regards
TK

On 10/18/2016 12:03 AM, Hardy Family hardy.woodland.cypress@gmail.c om [DynoMotion] wrote:

 

Hi Tom,

We are in the process of debugging our 5-axis changes.  Occasionally, we are getting floating point errors in void RoundCorner(int is) in TrajectoryPlanner.cpp.  We haven't touched that code, but nevertheless we're probably torturing it.  Just wondering if you can provide some insight.

It fails at the line
double l=sqrt(R*R-Z*Z);

in the loop where it is generating the facet segments.  R is less than Z.  It seems to be something to do with our segments having relatively large changes in the A,B axes and small changes in XYZ.  So (local var) 'Z' is computed from the 5-D "chord length" of the segment, however the corner radius R is calculated in 3-D since a 5-D radius is probably difficult to define.

Perhaps the calculation of Z should ignore the rotary axes?

I must admit to not understanding the implications of continuous 5-axis on this algorithm.  After all, what is a corner arc in 5-D?  I can understand the concept of a 5-D quadratic Bezier curve, which basically amounts to accelerating each axis independently to achieve the required velocity change.  But an arc doesn't seem to have the required degrees of freedom.

Regards,

SJH

I don't think 5th order is what we want at all.  I think an optimal planner would basically do maximum Jerk (or zero) and maximum Acceleration (or zero) all the time.  That gives optimal performance with limited Jerk.  We would not want to necessarily have low Jerk or Zero Acceleration at the beginnings and endings of the curves.  I think the thing to do is to use cubic splines but make the curves such that the accelerations match at junctions.  But I think this is very difficult. 

I also think the path needs to be altered.    For example consider a racetrack shape (two half circles with straight sections).  It is impossible to follow that path exactly while not allowing infinite Jerk without requiring a complete stop at the points wherever curvature changes.  So the path needs to be altered slightly (within a specified tolerance) in a way that minimizes rate of change of curvature.  Which I suppose is what race car drivers do naturally.

Regards

TK

 

It turns out that a 5th order Bezier can be constructed to have exactly zero acceleration at the start and end.  This happens when the 3 control points at each end are collinear and equally spaced.  So in principle, you could just have a flag that says "treat these 4 control points as if they were 6, and construct the missing ones as the midpoints of the first and last pair".  Then, if the kflop supported cubic Beziers, it could also handle these cheesy 5th order ones as well, and lo and behold there would be jerk control.  Of course, your interpolator has slightly more work do do, but the extra control points would not need to be stored anywhere since they are just the mean of each end pair.

On Thu, Oct 27, 2016 at 12:41 PM, Hardy Family <hardy.woodland.cypress@...> wrote:

Actually, I just had another thought on the jerk control, and I'm excited to actually try this out.  (My colleague is waiting ready to test on the machine, but he'll have to cool his heels...)

As you mentioned, a cubic Bezier is constant jerk.  So although we can't set it to zero, we can reduce it provided we are not too hung up on exact arc shapes.

That 0.45 constant I mentioned; that just gives a circular arc.  But if it is reduced (even made a bit negative) then the overall radial acceleration jump would be reduced at the start and end.  The price to pay is that the tangential velocity changes: it reduces towards the corner, then speeds up again.  And it's no longer circular, but more hyperbolic.  You can even set it to momentarily stop dead at the corner (with a bit of overshoot) - that would be when there is a cusp.  Go too extreme and it will actually loop around the wrong way.

Anyway, it is just another parameter that can be played with.  It would allow trade-off between amount of jerk control and keeping up the feed rate.  Optimum feed is at the arc setting, since the acceleration is distributed over the longest available time, but allowing it to slow down in the corners wouldn't hammer the machine so much.

Regards,

SJH

On Thu, Oct 27, 2016 at 12:09 PM, Hardy Family <hardy.woodland.cypress@gmail. com> wrote:

Hi SJH,

This is very interesting.  I can't say I fully understand it.  Here are some questions:

#1 it isn't clear if you are intending to only use the Bezier to define the path, or also using it to define the motion vs time.

Both.  We are only generating "boring" Bezier curves just for the purpose of rounding corners, but since they have some remaining degrees of freedom then these are used to match entry and exit velocities as well.

#2 can you elaborate more on how the path error is controlled?

Since we're only using this for corner rounding, the problem amounts to "how do we place this curve so that it is tangent to the entry and exit segments, and the midpoint is X distance from the sharp corner point".  So what I do is pick two points 1 unit away from the intersection point and on the entry and exit segs.  This is CP0 and CP3 (ends of the Bezier).  Then CP1 and CP2 are placed about 0.45 units from the corner.  This automatically gives a very close approximation to an arc.  Then evaluate the curve at t=0.5, calculate its distance from the corner.  Then geometrically expand/contract the curve proportionally so that it ends up with midpoint at the right distance.

#3 you state: "this is all done in actuator space".  Is it?  The Corner rounding is normally performed in CAD Space.   In Actuator space path errors aren't easily determined.

I think I'm guilty of sloppy terminology.  This is working in actuator space (scaled to inch/degree) but the assumption is that the scale is small enough that non-linearity is not an issue.  When physical displacements are required (e.g. CAD space distances) then the coords are transformed back and forth as required.

We have also split tolerances up into separate positioning and orientation measures, which makes it a bit easier to relate errors back into CAD space.

 

#4 I don't get the "variable parameter (t) intervals" stuff.  Can you elaborate?

It would create different lengths e.g. first one from t=0..0.1 then the next from 0.1..0.3.  It would depend on curvature etc.

I don't really like the way I did it, so I'm going back to a fixed interval approach.  Basically, I can do a bit of calculus on the curve and work out the optimum time step which will maintain acceleration vectors within the allowable envelope.

 

#5 you state: "for replacing multiple curve-approximating segments (at roughly constant speed), then the PC library can optimize its use fairly well".  I don't really see curves as constant speed or how they could be optimized if they are a single Bezier curve.

As a replacement for SEG_ARC motion, Beziers over less than 45 degrees are equivalent, and don't have the axis alignment restriction.  My comment there was referring to typical NC generators which produce a sequence of points, but with a constant feed rate.  If the underlying curves are fairly smooth, then it's not too hard to turn them back into a sequence of arc-like Beziers.

Of course, there are crazy Beziers with cusps and the like which would be varying speed, but I doubt these would be useful.  Just stick to boring ones.

 

Please don't take these as critiques.  Just trying to understand.

We're certainly open to adding Bezier functions if it makes sense (which it probably does).  The main drawback I see is that I think it would be almost twice the memory size as our current linear/arc segments.  I think the cubic Bezier can be defined as either 4 points or a 3rd order polynomial for each axis.  Both contain the same amount of data.  I'm thinking the 3rd order polynomials would be in a faster form to process but might have slightly worse numerical issues (small differences between large products issues).

It would be unfortunate if it took up more memory (even if not used), like you had to add more fields to each array element.

Avoid direct polynomial coeffs at any cost.  I imagine that you currently have something that generates 't' in the range 0..1 based on the a,b,c,d coeffs.  Then you interpolate the given segment start end using

P = start*(1-t) + end*t

so I would think that you simply change this to

P = start*(1-t)^3 + 3*cp1*t*(1-t)^t + 3*cp2*t^2*(1-t) + end*t^3

But isn't it really only 3 points, since the first point is the end of the last segment, as for linears?  Or does that point need to be explicitly saved?

 

On a somewhat off topic subject and hopefully not a distraction.  Have you ever considered 3rd order/Jerk limited trajectory planning and how that might fit into this?  Arcs smooth the first derivatve but still result in sudden changes in curvature which creates infinite Jerk.  I believe a Bezier is a constant Jerk thing.  But at the endpoints the accelerations can be different resulting in infinite Jerk the same as arcs.  It has always seemed to me that to do proper 3rd order planning going exactly through the waypoints would be very sub-optimal.

Yes, I though about that.  One could use 5th order Beziers to achieve 2nd order geometric continuity at both ends.  But the math starts to get nasty so I'm studiously ignoring that problem for now.

Regards,

SJH

 

Regards
TK

On 10/26/2016 11:35 PM, Hardy Family hardy.woodland.cypress@gmail.c om [DynoMotion] wrote:

 

We have made some progress.  The corner rounding now uses a cubic Bezier instead of a circular arc, so it is more robust for 5 axis.  Even a break angle of 90deg gives close enough to an arc.

It's actually not difficult to compute corner tolerances for the Bezier.  There's a simple formula for making a close approximation to a circular arc, and if an initial guess it taken, then because everything is linear at this scale, it is simple to scale it so that it passes a known tolerance from the specified point (segment intersection in this case).  The math is fairly trivial compared to the tangent arc case.  (Ok, maybe it's just me but I prefer vector math to trig!)

I also worked out a way of manipulating it so that it can match different tangential speeds at either end, while still being within the specified tolerance.

In RoundCorner(), it subdivides the Bezier into linear segments at variable parameter (t) intervals so as to maintain a specified target "velocity impulse" i.e. radial velocity increments at the segment junctions.  If the segments become too short (about 360us) then we reduce the MaxVel to force it to slow down enough that the impulses are not exceeded.  If there is different feed rate for entry and exit segments, then the change in feed rate is distributed along the curve linearly by t.  (Our post processor generates lower F numbers when it thinks there is fine detail, then speeds up on the "straights", so this smooths things out a bit, although it's probably redundant since the motion planner does this automatically.  But maybe it allows the segments to be "done" with less work.)

Since this is all done in actuator space, and each axis component is separable, the adaptive step size allows handling different actuator capability etc.

So now we are generating maybe 1-2000 LHex1 commands per second, or about 1Mbit/sec on the USB.  I think we would sustain this on a complex mold pattern.

I haven't tested this yet on a real machine, only a bare kflop, but analysis of the dumped segment output looks good so far.

Hopefully this will be satisfactory, but since our machine is intended for very fine mold work we wish to have the best finish possible.  We'll see how it goes, but what do you think of the prospect of adding native Bezier support to the kflop firmware?  This would be a command which allows two control points in addition to the start+end points, then the kflop would use Bezier interpolation instead of the current linear.  This would allow us to basically do away with the complex curve subdivision in RoundCorner(), and would reduce the bandwidth requirement, and of course it would give the ultimate smoothness.

Your point about losing some level of control as the curve progresses is valid, but I think if the use of this is for replacing multiple curve-approximating segments (at roughly constant speed), then the PC library can optimize its use fairly well.  Indeed, my happiness would be complete with kflop Beziers.  Such power! :-)

Regards,

SJH

On Thu, Oct 20, 2016 at 9:05 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Hi SJH,

It isn't clear to me why TCPC would change things.  I would think you would want to smooth/round the xyz path regardless.

Regarding quadratic or cubic beziers: Sounds interesting I suppose that would be reasonable.  But the problem I have with those is that I don't know how to determine them in a way with a known path tolerance.  

Also I wonder if keeping the Time the same would work where the original uses constant velocity and the other accelerates/decelerates.  I've seen weird results (ie curly queues or huge Jerks) if the time span is improper.

Another issue is that using a single formula for a curve (rather than small line segments) means that each portion of the curve can't be optimized the way it currently is.  For example consider a quarter circle curve.  The velocity/acceleration limits might be different for x and y.  Or even if they are the same when moving both the capability may be higher than either individually.   Also for non-linear systems it is difficult to determine if any of the actuator constraints are violated at any portion of the curve.

If you are able to determine the angle changes are minor, then these issues may not be significant.

HTH

Regards

TK

On 10/18/2016 5:36 PM, Hardy Family hardy.woodland.cypress@gmail.c om [DynoMotion] wrote:

 

Hi Tom,

As I mentioned, although in passing only, we have made extensive changes to CoordMotion.cpp and Kinematics.cpp to support g43.5 (TCPC) modes, so in this case there is no concept of rotary axis "radius" since the g-code IJK coordinates transform to a tool orientation and XYZ are relative to the (rotating) workpiece.  I think our problem arises when XYZ are not moving much, but the orientation vector is.  There are several unsatisfactory hacks I put in just to get it working.  Basically, a "pure angular" move should always execute at a rate limited by axis motor

(Message over 64 KB, truncated)

Hi SJH,

All interesting see below:

BTW I think we might be making a mistake mixing this discussion with the discussion of 3rd order planning.

 

I'll address your points below, but we are already testing some of these ideas on our machine.  We are comparing performance with uncontrolled jerk (circular arcs) and jerk control as described below.  Looks good so far in both cases, but we have yet to look carefully at the results.  We are breaking the curves into segments that take 720us to run, based on equal (parametric) subdivision of the Bezier curve.  We haven't yet had the courage to try 90us segments, but I don't think there's much to be gained by doing that. 

>>> Nice.  Yes I don't think 90us would make sense.  It would be too high of a data rate and make each segment just a point.

The velocity of each segment (MaxVel) is recomputed to be what is "natural" for linear progress of the t parameter, which allows us to calculate accelerations up front using simple vector differentiation.

>>> I don't follow this.  We're not supposed to change the feedrate and an analysis of the segments before and after are required to have any  idea of what the speed/accelerations might be.

It turns out that if we concentrate on the problem that is important to solve (namely, being able to sustain continuous motion around corners, with jerk control) then the solution is remarkably simple and elegant.

>>> I don't think that is adequate.  Especially with jerk control.  For example if it takes 50ms to ramp up the Acceleration and we decide to ramp the acceleration up from zero and back down to zero every few milliseconds the performance will be terrible.  I might be missing something.

It is possible to get zero acceleration at both ends of the curve using just a 4th order Bezier with control points in a very simple form:

P0: start point (on entry segment)

P1: midpoint between P0 and P2

P2: intersection point of entry and exit segments

P3: midpoint of P2 and P4

P4: end point (on exit segment)

P0,1,2 are collinear and equally spaced, as are P2,3,4.  This satisfies the condition for zero initial and final acceleration.  The only parameters that we are free to vary are the positions of P0 and P4, which can be used to match entry and exit velocity, and the corner rounding tolerance.

>>> Again I think multiple cubics are the best choice.  Higher orders would potentially be smoother in the higher order derivatives but at a large decrease in performance.  Even with 3rd order, short segments take much more time to get to speed using instant full maximum allowed Jerk.  So if we decide to ramp up Jerk it will be even slower.

Because the acceleration profile is parabolic, and zero at both ends, the maximum acceleration occurs at t=0.5.  With a 90 degree change in direction, the velocity dips to 1/sqrt(2) at this point relative to the entry/exit velocity, so obviously such sharp corners will take longer to complete than the equivalent circular arc, but that's the price to pay for jerk control.

>>> I think this illustrates my point.  You can loop around a circle at full/smooth speed/acceleration with low Jerk not costing you anything.

Now to the points you raise:

When we look at the bigger picture, it would be nice to match accelerations at each point.  E.g. if it is known that a g-code arc is being traced, then we don't really want so set the acceleration to 0 at each junction (that would make the machine vibrate unnecessarily).  However I think that having a choice between 3rd and 4th order corners would cover this case: use 3rd order for known arcs and 4th order for "random" changes of direction.  But this is a higher level of planning than what I'm trying to do here.

Yes, it's impossible to follow lines and tangent arcs exactly, but I don't understand why you see this is a problem in practice.  Probably I'm missing your point.

>>> I hope we can get on the same page with this as I think it is essential for doing 3rd order motion.  I'm not saying it is impossible to follow lines and arcs exactly, but if you do then it will force exact stops everywhere.  So it is essential to modify the path in a way that smooths out changes in curvature to the maximum extent possible without deviating from the required path by more than the allowed tolerance. 

  I'm really only interested in sustaining continuous motion when post processors are outputting lots of closely spaced points.  So whether the corner is rounded with an arc or a hyperbola doesn't much matter.  Of course it would be nice if the kflop could trace out a big old twisty Bezier but we'd never use that.

Regards,

SJH

Looking forward to some results/data.
Regards
TK

On Fri, Oct 28, 2016 at 10:54 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

I don't think 5th order is what we want at all.  I think an optimal planner would basically do maximum Jerk (or zero) and maximum Acceleration (or zero) all the time.  That gives optimal performance with limited Jerk.  We would not want to necessarily have low Jerk or Zero Acceleration at the beginnings and endings of the curves.  I think the thing to do is to use cubic splines but make the curves such that the accelerations match at junctions.  But I think this is very difficult. 

I also think the path needs to be altered.    For example consider a racetrack shape (two half circles with straight sections).  It is impossible to follow that path exactly while not allowing infinite Jerk without requiring a complete stop at the points wherever curvature changes.  So the path needs to be altered slightly (within a specified tolerance) in a way that minimizes rate of change of curvature.  Which I suppose is what race car drivers do naturally.

Regards

TK

On 10/27/2016 6:11 PM, Hardy Family hardy.woodland.cypress@gmail. com [DynoMotion] wrote:

 

It turns out that a 5th order Bezier can be constructed to have exactly zero acceleration at the start and end.  This happens when the 3 control points at each end are collinear and equally spaced.  So in principle, you could just have a flag that says "treat these 4 control points as if they were 6, and construct the missing ones as the midpoints of the first and last pair".  Then, if the kflop supported cubic Beziers, it could also handle these cheesy 5th order ones as well, and lo and behold there would be jerk control.  Of course, your interpolator has slightly more work do do, but the extra control points would not need to be stored anywhere since they are just the mean of each end pair.

On Thu, Oct 27, 2016 at 12:41 PM, Hardy Family <hardy.woodland.cypress@gmail. com> wrote:

Actually, I just had another thought on the jerk control, and I'm excited to actually try this out.  (My colleague is waiting ready to test on the machine, but he'll have to cool his heels...)

As you mentioned, a cubic Bezier is constant jerk.  So although we can't set it to zero, we can reduce it provided we are not too hung up on exact arc shapes.

That 0.45 constant I mentioned; that just gives a circular arc.  But if it is reduced (even made a bit negative) then the overall radial acceleration jump would be reduced at the start and end.  The price to pay is that the tangential velocity changes: it reduces towards the corner, then speeds up again.  And it's no longer circular, but more hyperbolic.  You can even set it to momentarily stop dead at the corner (with a bit of overshoot) - that would be when there is a cusp.  Go too extreme and it will actually loop around the wrong way.

Anyway, it is just another parameter that can be played with.  It would allow trade-off between amount of jerk control and keeping up the feed rate.  Optimum feed is at the arc setting, since the acceleration is distributed over the longest available time, but allowing it to slow down in the corners wouldn't hammer the machine so much.

Regards,

SJH

On Thu, Oct 27, 2016 at 12:09 PM, Hardy Family <hardy.woodland.cypress@gmail. com> wrote:

Hi SJH,

This is very interesting.  I can't say I fully understand it.  Here are some questions:

#1 it isn't clear if you are intending to only use the Bezier to define the path, or also using it to define the motion vs time.

Both.  We are only generating "boring" Bezier curves just for the purpose of rounding corners, but since they have some remaining degrees of freedom then these are used to match entry and exit velocities as well.

#2 can you elaborate more on how the path error is controlled?

Since we're only using this for corner rounding, the problem amounts to "how do we place this curve so that it is tangent to the entry and exit segments, and the midpoint is X distance from the sharp corner point".  So what I do is pick two points 1 unit away from the intersection point and on the entry and exit segs.  This is CP0 and CP3 (ends of the Bezier).  Then CP1 and CP2 are placed about 0.45 units from the corner.  This automatically gives a very close approximation to an arc.  Then evaluate the curve at t=0.5, calculate its distance from the corner.  Then geometrically expand/contract the curve proportionally so that it ends up with midpoint at the right distance.

#3 you state: "this is all done in actuator space".  Is it?  The Corner rounding is normally performed in CAD Space.   In Actuator space path errors aren't easily determined.

I think I'm guilty of sloppy terminology.  This is working in actuator space (scaled to inch/degree) but the assumption is that the scale is small enough that non-linearity is not an issue.  When physical displacements are required (e.g. CAD space distances) then the coords are transformed back and forth as required.

We have also split tolerances up into separate positioning and orientation measures, which makes it a bit easier to relate errors back into CAD space.

 

#4 I don't get the "variable parameter (t) intervals" stuff.  Can you elaborate?

It would create different lengths e.g. first one from t=0..0.1 then the next from 0.1..0.3.  It would depend on curvature etc.

I don't really like the way I did it, so I'm going back to a fixed interval approach.  Basically, I can do a bit of calculus on the curve and work out the optimum time step which will maintain acceleration vectors within the allowable envelope.

 

#5 you state: "for replacing multiple curve-approximating segments (at roughly constant speed), then the PC library can optimize its use fairly well".  I don't really see curves as constant speed or how they could be optimized if they are a single Bezier curve.

As a replacement for SEG_ARC motion, Beziers over less than 45 degrees are equivalent, and don't have the axis alignment restriction.  My comment there was referring to typical NC generators which produce a sequence of points, but with a constant feed rate.  If the underlying curves are fairly smooth, then it's not too hard to turn them back into a sequence of arc-like Beziers.

Of course, there are crazy Beziers with cusps and the like which would be varying speed, but I doubt these would be useful.  Just stick to boring ones.

 

Please don't take these as critiques.  Just trying to understand.

We're certainly open to adding Bezier functions if it makes sense (which it probably does).  The main drawback I see is that I think it would be almost twice the memory size as our current linear/arc segments.  I think the cubic Bezier can be defined as either 4 points or a 3rd order polynomial for each axis.  Both contain the same amount of data.  I'm thinking the 3rd order polynomials would be in a faster form to process but might have slightly worse numerical issues (small differences between large products issues).

It would be unfortunate if it took up more memory (even if not used), like you had to add more fields to each array element.

Avoid direct polynomial coeffs at any cost.  I imagine that you currently have something that generates 't' in the range 0..1 based on the a,b,c,d coeffs.  Then you interpolate the given segment start end using

P = start*(1-t) + end*t

so I would think that you simply change this to

P = start*(1-t)^3 + 3*cp1*t*(1-t)^t + 3*cp2*t^2*(1-t) + end*t^3

But isn't it really only 3 points, since the first point is the end of the last segment, as for linears?  Or does that point need to be explicitly saved?

 

On a somewhat off topic subject and hopefully not a distraction.  Have you ever considered 3rd order/Jerk limited trajectory planning and how that might fit into this?  Arcs smooth the first derivatve but still result in sudden changes in curvature which creates infinite Jerk.  I believe a Bezier is a constant Jerk thing.  But at the endpoints the accelerations can be different resulting in infinite Jerk the same as arcs.  It has always seemed to me that to do proper 3rd order planning going exactly through the waypoints would be very sub-optimal.

Yes, I though about that.  One could use 5th order Beziers to achieve 2nd order geometric continuity at both ends.  But the math starts to get nasty so I'm studiously ignoring that problem for now.

Regards,

SJH

 

(Message over 64 KB, truncated)